I'll fix the formatting

Cool example. It will be really nice if you could add also a:

/drawjpg endpoint, that will receive the JPG file, decompress it and draw it on the display

but knowing that you make a Python Client is also ok. It’s just that this way could be easier for someone to send a JPG image from anywhere including a browser of any mobile device.
I’ve did 2 examples of JPG decompression that you can see in www-image one uses the ROM jpegd and the other is faster and uses Larry Bank JPEGDEC component. In the v7 there is a enough PSRAM to upload and decompress a quite fat image.

Thanks for the idea, I'll have a look. If adding JPG support will be easy, I'll do it

On a second thought, would you mind merging it now, and we can add the jpg endpoint later?
I think that having this server without jpg is better than not having it at all, and we can always improve the interface later

Looks interesting! I'll have a closer look and try it out hopefully later this week :)

A bit of early feedback from my side here:

1. If you clone this, switch to http-server branch and try to build it

undefined reference to `epd_lcd_deinit'

This is because is not taking esp32s3 as default target. sdkconfig.defaults should point to ESP32S3 target that is the last PCB. My advice, just copy: sdkconfig.defaults.esp32s3 to sdkconfig.defaults so the user can directly compile this for the last v7 PCB.

2. two configuration files:

   In main/server.h, edit WIFI_SSID and WIFI_PASSWORD to match your wifi config
   In main/main.c, edit n_epd_setup to refer to the right EPD screen

This could be ideally reduced to one settings.h header file or just one of them, where you can edit a single file and just build.
For me this would be beneficial for 1st time users of this example. You know as less complicated is better so there is more people getting it right from the 1st time. Other than that for me it works great and it's pretty fast too!

thank you all for the feedback!

hello @BackSlasher please do not force push like this because is hard to follow history. Usually you force push something when you want to go back to a certain point but not when you go forward correcting stuff.

I have no problem adapting to what's convenient to you :)
I personally find squashing (and as a result, force-pushing) to keep PRs to a single commit. From now on for PRs on this repo I will avoid this.

I have plans to test this further as soon as my boards arrive.

Regarding the force-pushing: I don't have a problem with this, do whatever you want in the PR; I squash before merge anyway ;)